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INTRODUCTION 

Purpose 


I I 


E 


The  purpose  of  performing  the  Special  Study  described  in  this 
document  is  twofold.  Both  aspects,  however,  are  intended  to 
analyze  the  use  of  the  Space  Shuttle  Orbiter  data  processing 
systems  in  satisfying  those  requirements  placed  on  the  Manned 
Aerospace  Support  Equipment  (MASE)  by  the  Space  Test  Programs' 
(STP)  Five-year  Plan. 

The  first  aspect  is  an  analysis  of  the  techniques  involved  and 
the  security  associated  with  isolating  one  of  the  Orbiter 's 
General  Purpose  Computers  (GPCs)  for  use  as  the  MASE  central 
processing  unit.  The  second  is  an  investigation  as  to  how  re- 
sponsive such  a system  would  be  to  the  typical  kinds  of  data 
processing  one  might  expect  on  experiments  assumed  to  be  of 
interest  to  the  STP. 


The  results  and  conclusions  presented  in  this  document  do  not 
represent  a recommendation  by  the  DOD  or  IBM  on  the  MASE  systems 
architecture,  but,  rather,  an  objective  analysis  of  the  Orbiter 's 
systems  as  applied  to  the  problem. 


1 . 2 Scope 

This  document  is  intended  to  accomplish  the  purpose  discussed 
above  by  addressing  the  following  topics.  Section  2 is  an 
Executive  Summary  which  includes  some  background  as  well  as  major 
points  of  interest  and  conclusions. 

Section  3 addresses  the  security  aspects  associated  with  isola- 
ting one  of  the  Orbiter' s five  General  Purpose  Computers  (GPC) 
for  the  purpose  of  supporting  sortie  mission  data  processing. 
Standard  measures  available  within  the  current  Orbiter 's  capa- 
bilities as  well  as  additional  security  measures  which  can  be 
taken  are  addressed. 


Section  4 develops  typical  data  processing  requirements  for 
experiments  assumed  to  be  of  interest  to  the  Department  of 
Defense  (DOD) . The  section  continues  by  analyzing  the  applica- 
tion of  the  isolated  GPC  to  those  requirements  in  terms  of 
response  time.  Some  necessary  augmentation  of  the  current 
system  to  handle  high  data  rate  input  and  video  imagery  is 
discussed. 

Section  5 goes  on  to  analyze  a system  where  the  GPC  is  replaced 
by  a spaceborne  microprocessor  of  capabilities  projected  for  the 
1985-1990  timeframe.  Improvements  in  the  speed  of  response  are 
presented  as  functions  of  two  configurations  of  the  system. 

Section  6 presents  a set  of  conclusions  and  recommendations. 


i 
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For  additional  information  relative  to  the  Orbiter  Data  Pro- 
ceaaing  System  (DPS) , the  reader  is  referred  to  "Software 
Engineering  for  Shuttle  Payloads"  (NAS  5-25370,  January  1979) . 
This  document,  specifically  Appendix  J,  gives  a broad  descrip- 
tion of  the  DPS  and  payload  interface. 
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2.0  EXECUTIVE  SUMMARY 

2 . 1 Background 

The  study  presented  in  this  document  was  prompted  from  a review 
of  the  Five-Year  Plan  for  Space  Test  Program,  28  August  1978. 
During  this  review  by  IBM,  it  was  noted  that  the  Space  Shuttle 
Orbiter's  data  processing  system  components  were  not  under  con- 
sideration as  candidate  elements  in  the  Manned  Aerospace  Support 
Equipment  (MASE)  system  since  the  Sortie  Concept  addressed 
"stand-alone"  systems  for  quick  response,  felxibility  and  se- 
curity. Discussions  with  STP  personnel  resulted  in  a briefing  by 
IBM  on  the  potential  applicability  of  Orbiter  equipment  to  sup- 
port MASE.  A review  of  the  hardware  and  software  available  and  a 
technique  for  isolating  one  of  the  Orbiter's  General  Purpose 
Computers  (GPC)  resulted  in  the  configuration  shown  in  Figure  2-1. 

In  this  configuration,  GPC  #2  (taken  as  a representative  one  of 
five)  is  functionally  isolated  from  the  others  and  is  electrically 
connected  to  the  experiment  pallet  and  experiments  over  the  Launch 
Data  Buses  (LDB) . One  of  the  GPCs  (in  this  case,  number  2)  and 
the  LDBs  are  usually  dormant  during  on-orbit  operations  and  may  be 
used  for  this  purpose.*  The  same  is  true  of  the  Display/Keyboard 
(DK)  bus.  For  on-orbit  operations,  Multi-Functional  CRT  Display 
System  (MCDS)  number  1 is  not  normally  used.  Since  all  computers, 
displays  and  buses  are  cross-strapped,  any  configuration  of 
elements  is  possible.  A fifth  MCDS  modified  for  video  is  added 
at  the  Aft  Flight  Deck  and  is  dedicated  for  MASE  purposes.  A 
third  Mass  Memory  Unit  (MMU)  with  potential  of  an  intermediate 
encryptor/decryptor  is  supplied  for  additional  security  of  DOD 
software  and  data.  Uplink,  time  and  data  stored  in  the  remaining 
computer  will  be  made  available  at  the  aft  station  by  NASA  as  a 
standard  service. 

The  briefing  prompted  a Special  Study  to  be  performed  under  the 
Orbiter  Avionics  System  Integration  Study  contract  held  between 
DOD  (LVJ)  and  IBM.  This  study  was  to  investigate  the  security 
aspects  of  the  suggested  configuration  and  the  applicability  of 
this  system  to  typical  DOD  experiment  processing  requirements. 

This  document  presents  the  results  of  that  study. 


•For  OFT,  GPC #2  may  be  used  as  a backup  GN&C  computer  during 
powered-flight  maneuvers  on-orbit.  We  assume  that  in  the  mature 
OPS  timeframe  this  will  not  be  necessary,  or  that  if  it  is  neces- 
sary, experiment  data  processing  would  not  be  performed  during 
powered  flight.  As  for  the  Launch  Data  Buses  (LDB),  they  would 
only  be  used  to  operate  the  Remote  Manipulator  System  (RMS)  on- 
orbit.  It  is  assumed  that  either  the  DOD  would  not  use  the  RMS 
or  would  suspend  payload  data  processing  during  RMS  operations. 
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Figure  2-1  Dedicated  GPC/MMU  System 
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Security 


An  analysis  was  performed  to  determine  the  techniques  and  security 
risk  associated  with  isolating  .1)  the  DOD  GPC  from  the  rest,  2) 
the  remaining  four  GPCs  from  the  DOD  GPC  and  its  data  buses,  3) 
both  systems  from  the  other's  Mass  Memories  and  4}  the  DOD  GPC 
from  the  Orbiter's  telemetry  stream.  Standard  error  control 
measures  in  the  GPCs,  the  isolation  effects  of  causing  the  DOD 
GPC  to  become  "out  of  sync"  with  the  remaining  set  and  some 
special  measures  which  might  be  taken  to  increase  security  were 
reviewed.  It  was  determined  currently-available  measures  in  the 
Orbiter's  data  processing  system  would  provide  at  least  three 
levels  of  depth  in  system-to-system  isolation. 

A review  of  the  TEMPEST  testing  program  was  given.  No  regard 
to  internal  (to  the  Orbiter)  testing  has  been  given,  but  TEMPEST 
problems  are  not  expected  due  to  "sound  electromagnetic  interference 
practices"  being  employed  during  Orbiter  construction. 

Multi-experiment  handling  in  the  GPC  was  discussed  and  an  avail- 
able software  technique  to  separate  programs  and  data  was  pre- 
sented . 

2.3  Experiment  Data  Processing 

Experiment  data  processing  requirements  for  digital  imagery  and 
Synthetic  Aperture  Radars  (SAR)  were  generated  (Section  4) . 

Contrast  enhancement,  magnification/demagnification,  Fourier  trans- 
forming and  SAR  image  forming  were  considered.  After  a descrip- 
tion of  the  processes,  actual  processing  requirements  were  pre- 
sented . 

2.4  GPC-Oriented  System  Response 

The  ability  of  the  system  described  in  Section  2.1  to  meet  the 
requirements  generated  in  Section  4 is  presented.  It  is  shown 
that  with  proper  augmentation  to  handle  video  and  high-speed 
buffering  of  experiment  data,  most  presumed  processing  require- 
ments could  be  handled  at  reasonable  rates.  For  example,  the 
problem  of  reducing  a 1024 2 digital  time  image  to  a 512*  for  video 
display  requires  around  16  seconds.  The  same  problem  on  data 
transformed  by  a Fast  Fourier  Transform  requires  around  one 
minute. 

2.5  Microprocessor-Augmented  System  Response 

A system  wherein  the  GPC  is  replaced  by  a microprocessor  whose 
characteristics  are  estimated  from  computer  technology  projec- 
tions is  discussed  in  Section  5.  Technological  predictions  for 
processors  and  memory  devices  were  surveyed  and  two  systems 
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analyzed:  One  where  the  mass  storage  device  is  arrayed  to  the 
point  that  the  microprocessor  becomes  saturated  and  the  other  - 
a more  simple  and  less  costly  system  - where  a single  state-of- 
the-art  spaceborne  memory  is  used  where  the  microprocessor  is 
then  matched  in  speed  with  the  memory.  Predicted  systems  re- 
sponse (as  compared  to  the  GPC-oriented  system)  becomes: 

l: 

L 

Single  Arrayed 

GPC  Memory  Memory 

Function  System  System  System 

Demagnification  16  sec.  0.8  sec  0.1  sec 

(1024*  - 512*) 

512 2 Fourier  Transform  63  sec  3 sec  1 sec 

It  is  noted  that  system  response  is  inversely  proportional  to 
cost  and  power  consumption  and  that  the  appropriate  tradeoffs 
should  be  performed  before  an  ultimate  decision  is  made. 

2 . 6 Key  Points 

The  major  points  brought  out  in  this  study  are: 

e A single  GPC  can  be  isolated  from  the  remaining  set 
of  four  with  at  least  three  levels  of  error  checking 
as  insulation.  This  is  accomplished  by  causing  a com- 
puter to  appear  failed  to  the  remaining  set  and  would 
require  little,  if  any,  reverification  of  the  system. 

e Multi-experiment  processing  in  one  computer  can  be 
handled  securely  by  an  available  software  feature. 

Additional  protection  may  be  available  through  other 
means  (secure  operating  systems,  distributive  pro- 
cessing systems,  etc.). 

• The  Orbiter's  GPC,  with  proper  augmentation  (i.e.,  a 
video  generator  and  a high-speed  experiment  data 
memory  device)  can  produce  digital  imagery  in  respect- 
able response  times. 

e A system  utilizing  projected  (1985-1990)  technology  and 
utilizing  the  GPC  as  the  executive  controller  can  offer 
shorter  response  times  at  cost  and  power  penalties. 

IBM  is  not  recommending  the  use  of  any  one  system,  at  this  point. 

The  intent  of  this  document  was  only  to  address  the  use  of  the 
GPC  as  a MASE  component  and  to  perform  a preliminary  comparison 
of  its  performance  against  the  kind  of  performance  which  is  pre- 
dicted to  be  available  from  systems  in  the  1985-1990  timeframe. 
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GPC  ISOLATION  AND  SECURITY 


3.1  Description  of  the  Problem 

The  GPCs  in  the  Space  Shuttle  operate  the  Data  Processing  System 
(DPS)  through  twenty- four  data  buses  which  they' control . Twenty- 
three  of  these  buses  are  common  to  all  five  computers.  The 
remaining  bus  is  unique  to  each  computer  and  goes  to  the  Telemetry 
Master  Unit.  When  operating  redundantly,  the  General  Purpose 
Computers  (GPCs)  divide  up  the  buses  bo  that  only  one  GPC  has 
command  of  any  one  bus  with  the  others  passively  receiving  data  on 
that  bus  but  issuing  no  commands  or  outputs  on  it.  Thus,  for 
example,  for  the  four  buses,  each  connected  to  one  of  the  four 
redundant  rate  gyros,  each  GPC  is  issuing  commands  for  acquiring 
data  on  one  of  them  but  is  receiving  data  from  all  of  them. 

This  arrangement  gives  rise  to  the  problem  of  defining  a way  in 
which  to  absolutely  isolate  one  of  the  computers  from  the  others  and 
devote  it  to  DOD  operations  without  danger  of  letting  DOD  classified 
data  or  code  escape  into  the  primary  system.  The  problem  amounts  to 
showing  how  to  reliably  deadface  ell  data  paths  between  the  GPC 
doing  DOD  work  and  the  other  GPCs  which  are  operating  the  Space 
Shuttle. 

3.2  Data  Flow 

Figure  3-1  shows  the  proposed  configuration.  The  buses  to  be  used 
by  the  DOD  computer  are  shown  ( LDB,  and  DK-2 ) as  well  as  the  primary 
system  mass  memory  buses.  For  simplicity,  the  other  buses  are  not 
shown. 

In  order  to  understand  the  methodology  of  isolation,  it  is  necessary 
to  understand  in  some  detail  the  data  flow  into  and  out  of  the  GPC. 
The  pertinent  elements  are  shown  in  figure  3-2.  This  figure  shows  a 
portion  of  the  Input  Output  Processor  (IOP)  in  which  the  Multiplexed 
Interface  Adapter  (MIA)  is  separated  from  the  rest  of  the  IOP,  even 
though  the  24  MIA's  (one  per  bus)  are  physically  packaged  into  the 
IOP. 


The  process  for  obtaining  data  from  a subsystem  is  as  follows.  The 
program  in  the  Central  Processing  Unit  (CPU)  issues  the  appropriate 
commands  to  enable  the  transmitter  and  receiver  by  setting  the 
appropriate  bits  in  the  transmit  enable  and  receive  enable 
registers.  This  is  done  via  a Program  Controlled  Output  (PCO). 
Each  bus  is  enabled  separately  with  a unique  bit  in  the  registers. 
Next,  the  Bus  Control  Element  (BCE)  must  be  enabled,  if  it  is  not 
already  so,  by  resetting  the  halt  bit  in  the  status  register.  There 
is  one  BCE  for  each  bus,  each  with  a halt  bit  in  the  status  register. 


Figure  3-1  GPC  I/O  Functional  Diagram 


The  BCE  cannot  execute  any  instructions  if  the  halt  bit  is  set.  The 
PCO  is  used  for  this  action.  Next,  the  CPU  tells  the  BCE  to  start 
and  it  begins  executing  instructions.  These  instructions  condition 
the  BCE  by  loading  into  its  local  storage  a time  out  value  and  the 
Interface  Unit  Address  (IUA).  The  time  out  value  determines  how 
long  the  BCE  will  wait  for  data  to  come.  If  the  time  is  exceeded,  an 
error  flag  will  be  set  and  the  BCE  stops.  The  IUA  is  the  address  of 
the  unit  from  which  the  data  is  desired.  This  will  be  compared  with 
each  word  of  received  data  which  must  have  the  same  address  or  the 
data  will  not  be  accepted. 

The  BCE  then  sends  the  encoder  the  command  which  causes  the  desired 
subsystem  to  send  data.  The  encoder  converts  the  command  into 
serial  manchester  code,  adds  appropriate  sync  bits  and  parity  bit 
and  ships  it  onto  the  bus  via  the  transmitter  (which  must  be 
enabled).  If  the  data  comes  back,  it  passes  through  the  receiver 
into  error  checking  circuitry.  The  sync  bits  are  checked,  the 
number  of  bits  in  the  word  are  checked  and  parity  is  checked.  The 
data  is  stopped  at  this  point  if  the  check  fails  and  an  error  bit  set 
in  the  status  register.  The  BCE  stops  with  any  error  indication. 
The  data  is  then  transferred  to  the  MIA  buffer.  If  the  time  out 
window  has  been  exceeded,  the  data  stops  at  this  point  because  the 
BCE  has  turned  itself  off  after  the  time  out  was  exceeded. 

If  all  checks  have  been  positive,  the  BCE  then  tests  the  incoming 
bits  for  the  correct  IUA  by  comparing  it  with  the  previously  stored 
IUA  of  the  outgoing  command.  The  data  stops  in  the  MIA  buffer  if  the 
test  is  failed.  Otherwise,  the  BCE  stores  it  into  the  main  memory. 
When  the  correct  number  of  words  has  been  received,  the  BCE  either 
drops  to  a wait  state  or  starts  another  Input/Output  operation. 

For  data  outputs  to  the  subsystem,  the  data  flow  is  the  same  as  the 
first  portion  of  the  above  (i.e.,  the  flow  of  the  command  to  the 
subsystem  for  data . ) 

The  technique  used  in  redundant  set  operation  can  now  be  explained 
more  precisely.  As  an  example,  where  there  are  four  redundant  buses 
for  receiving  the  data  from  four  redundant  rate  gyros,  each  of  the 
four  computers  has  control  of  one  each  of  the  buses.  Control  means 
that  the  MIA  transmitter  is  turned  on  via  the  transmit  enable 
register.  Thus,  on  each  of  the  redundant  buses,  one  IOP  has  the 
transmitter  on  and  the  other  three  have  only  the  receiver  enabled. 
The  command  to  the  rate  gyro  to  send  data  goe6  from  the  commander 
and  all  hear  the  data  coming  back.  However,  the  data  will  not  get 
into  the  other  computers  unless  preparation  has  been  made.  The 
receivers  must  be  on,  the  correct  IUA  must  have  been  set  into  the 
BCE,  the  correct  word  count  must  be  anticipated,  the  time-out  window 
must  be  set  up  with  appropriate  time  and,  etc.,  to  have  these  things 


set  up  at  the  right  time  ( + a few  milliseconds)  the  computers  must 
be  synchronized  so  that  the  I/O  tasks  are  started  together. 

The  synchronization  is  accomplished  by  handshaking  discrete  lines 
between  the  GPCs.  If  synchronization  is  lost  with  any  of  the 
computers,  the  primary  software  is  coded  to  stop  receiving  data  on 
any  of  the  buses  command  by  the  computer  failing  to  sync  (i.e.,  the 
receivers  on  those  channels  are  turned  off).  This  type  of  action 
protects  the  redundant  computer  set  from  bad  commands  and  data  from 
a failed  computer. 

All  of  the  data  checks  described  above  are  for  the  same  purpose 
i.e.,  the  word  count,  bit  count,  IUA,  time  out  parity  checks  will 
8 top  data  from  getting  into  a GPC  unless  it  is  synchronously 
executing  the  same  tasks  as  the  computer  controlling  the  bus. 

Proof  of  this  insensibility  to  spurious  signals  on  the  buses  is 
obtained  through  analysis  and  software  verification.  It  is  treated 
as  a safety  of  flight  item.  This  proven  ability  of  the  primary 
system  is  significant  to  the  DOD  use  of  one  of  the  onboard  computers 
during  orbital  operations.  It  essentially  guarantees  that  the 
primary  system  will  not  be  harmed  by  inadvertent  misuse  of  the  DOD 
computer  and  also  the  same  features  can  be  used  to  guarantee  that 
DOD  data  on  the  buses  commanded  by  the  DOD  computer  cannot  be  stored 
by  any  device  other  than  the  DOD  computer  DOD  display,  or  DOD  mass 
memory.  The  following  sections  will  point  out  how  this  can  be  done 
by  using  the  features  just  described. 

3.3  Isolation  Techniques 

The  following  discussion  is  organized  into  a description  of  a method 
for  starting  up  the  DOD  computer  and  then  a description  of  the 
isolation  provisions  at  each  interface  to  the  primary  system. 

3.3.1  Start  Up  Methodology 

At  the  initiation  of  the  DOD  start  up  the  selected  computer  will  be 
in  a powered-down  state.  Any  of  the  five  computers  can  be  selected; 
however,  it  must  be  one  of  the  machines  not  involved  in  the  primary 
system  which  is  operating  the  space  shuttle. 

Power  will  be  applied  to  the  selected  computer  and  an  Initial  Pro- 
gram Load  (IPL)  performed  using  the  IPL  switch.  The  initial  program 
will  be  read  in  from  the  primary  system  mass  memory  and  will  be  the 
same  as  IPL  for  the  primary  system.  When  this  action  is  complete, 
the  DOD  selected  computer  will  be  in  a loose  synchronization  with 
the  primary  set  executing  Mode  "O"  of  the  primary  software.  A list 
of  the  next  set  of  possible  keyboard  commands  can  be  displayed  under 
this  software.  One  additional  item  must  be  added  to  this  list 
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(currently,  there  are  several  vacant  spaces)  which  would  be  the 
command  to  load  a short  program  for  reading  the  DOD  mass  memory. 
These  two  small  pieces  of  code  would  be  the  only  changes  required  in 
the  primary  software. 

The  program  read  in  would  go  only  to  the  DOD  computer,  and  this 
could  be  checked  via  the  display.  This  program  would  be  complete 
except  that  the  IUA  of  the  DOD  mass  memory  would  be  missing.  This 
key  address  would  be  added  manually  to  the  DOD  computer  only  via  the 
primary  system  keyboard.  The  display  could  be  used  to  check  that 
only  the  DOD  computer  received  it. 

Next,  the  execute  command  would  be  entered  and  the  DOD  computer 
would  load  its  operational  program  from  the  DOD  mass  memory.  No 
other  unit  in  the  orbiter  system  would  have  the  same  address  as  the 
DOD  memory  so  that  the  primary  system  can  never  address  it,  the 
address  will  not  exist  on  the  primary  mass  memory  or  in  the  primary 
computer.  This  is  the  rationale  for  manual  entry. 

At  the  point  of  reading  in  the  DOD  program,  synchronization  will  be 
broken  and  a light  will  come  on  verifying  this  has  happened.  This 
reaction  is  already  programmed  in  the  primary  software  for  the 
"fail-to-6ync"  condition.  In  addition,  the  primary  system  turns  off 
the  MIA  receivers  in  the  data  bus  channels  assigned  to  the  non- 
synchronizing GPC . This  again  is  programmed  and  verified  already  in 
the  primary  software  to  guard  against  a failed  GPC  sending  bad  data 
into  the  redundant  set.  The  DOD  computer  is  now  loaded  with  the  DOD 
operating  program  which  interfaces  with  the  DOD  equipments  only 
since  the  IUA's  of  the  DOD  system  elements  are  all  different  from 
any  in  the  primary  system. 

3.3.2  Isolation  of  Data  on  DOD  Buses 

The  concept,  as  shown  in  figure  2-1  is  to  dedicate  three  buses  to 
the  DOD  computer.  These  are:  the  two  launch  data  buses  and  the  DK-2 
display  bus.  The  question  addressed  in  this  section  is  that  of 
making  certain  that  no  data  on  these  three  buses  can  be  stored  in 
any  of  the  primary  system  elements  which  have  memory.  This  is  of 
concern  because  the  primary  system  elements,  displays  and  computers 
are  still  electrically  connected  to  these  buses. 

There  are  several  protections  provided.  First,  it  is  proposed  that 
all  of  the  DOD  units  have  lUA's  which  are  different  from  those  of 
any  primary  system  element.  Plenty  of  spare  addresses  are  available 
to  accomplish  this.  The  IUA  check  at  the  primaiy  system  display  or 
GPC  would  then  automatically  reject  any  message  sent  by  any  element 
of  the  DOD  system.  The  IUA  of  the  primary  system  display  on  the  DK-2 
bus  is  hard  wired  via  a code  plug  and  would  also  be  different. 
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Secondly,  the  primary  display  on  DK-2  would  be  turned  off. 


Thirdly,  the  loss  of  sync  at  the  outset  turns  off  the  receivers  on 
these  buses  in  the  primary  system.  This  can  be  checked  if  desired 
by  a callable  display  format  in  the  primary  system.  This  stops  any 
information  at  the  receiver. 

Finally,  the  lack  of  synchronization  would  make  it  impossible  for 
the  primary  system  to  start  the  receive  process  at  the  right  time. 
(Time-out  windows  would  be  wrong,  word  counts  would  be  wrong,  etc. ) 
The  above  provisions  give  three  to  four  levels  of  protection  against 
inadvertent  acquisition  of  DOD  data  by  the  primary  system. 

3.3.3  Transmission  of  DOD  Data  on  Unauthorized  Buses 

This  concern  is  that  of  the  DOD  computer,  either  through  a software 
or  a hardware  failure,  transmitting  on  buses  being  used  by  the 
primary  system.  In  this  case,  the  receivers  in  the  primary  system 
would  be  enabled. 

The  DOD  software  would  be  programmed  to  turn  off  the  transmitters  on 
all  MIAs  interfacing  these  buses.  This  would  be  cyclically  done, 
say  at  25  H2.  In  the  same  manner,  the  BCEs  would  be  put  in  a halt 
state.  This  could  be  checked  via  the  DOD  display,  if  desired. 

In  addition,  the  primary  system  could  not  receive  the  data  anyway 
since  no  primary  system  IUA  would  be  stored  anywhere  in  the  DOD 
system.  The  lack  of  synchronization  again  makes  it  impossible  for 
the  primary  system  GPC  to  set  up  the  receive  operation  at  the  right 
time  for  the  time  out  windows . I f the  DOD  computer  happened  to 
transmit  at  the  same  time  as  a primary  computer  or  subsystem  on  a 
Particular  bus,  the  parity  checks,  bit  count  checks,  and  sync  bit 
checks  would  be  failed  by  all  of  the  primary  system  Display  Sets  and 
computers  in  addition  to  the  aforementioned  protective  feature.  The 
time  out  windows  and  BCE  start  commands  in  the  primary  system  would, 
of  course,  be  timed  for  expected  data  so  that  if  DOD  data  arrived 
when  the  primary  BCE  was  active  it  would  almost  certainly  be 
intermixed  with  primary  data  and  both  would  be  rejected  as  noted.  If 
it  arrived  when  the  primry  BCE  was  not  active,  it  would  go  no 
further  than  the  MIA  buffer. 

3.3.4  Primary  Mass  Memory  Interface 

Of  separate  concern  is  the  possibility  of  writing  on  the  primary 
mass  memory  by  mistake.  In  this  case  the  protection  is  four  deep. 
The  DOD  BCE's  on  the  channels  controlling  the  primary  mass  memory 
buses  will  be  halted  and  tha  transmitters  turned  off.  The  IUA  of 
the  primary  mass  memory  will  not  be  stored  anywhere  in  the  DOD 
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System.  In  addition,  no  code  to  start  or  run  the  BCE  controlling 
these  channels  will  exist  in  the  DOD  computer  program.  These  exact 
same  safeguards  also  prevent  spurious  transmissions  being  received 
by  the  primary  system  display  units. 

3.3.5  Telemetry  Interface 

All  of  the  safeguards  of  paragraph  3.3.4  exist  in  regard  to 
inadvertent  transmission  to  the  telemetry  system  over  the  telemetry 
data  bus.  In  addition,  it  would  be  possible  to  alter  the  telemetry 
format  load  so  that  during  DOD  operation  the  PCM  master  unit  would 
not  read  the  buffer  which  is  dedicated  to  the  computer  selected  for 
the  DOD  operation. 

3.3.6  Unauthorized/Unplanned  Use  of  DOD  Mass  Memory 

When  the  DOD  mass  memory  is  not  being  used,  it  could  be  addressed 
and  read  by  one  of  the  primary  GPC ' s . This  normally  would  not 
happen  because  the  primary  system  does  not  have  the  IUA,  the 
transmitter  is  turned  off,  the  receiver  is  turned  off,  and  there  is 
no  primary  program  to  address  a mass  memory  on  that  data  bus . 

However,  at  one  point  in  the  investigation,  the  question  of  sabotage 
was  raised,  i.e.,  illegal  code  planted  in  the  primary  system. 

This  particular  sabotage  threat  is  preventable  by  having  the  DOD 
software  send  status  check  commands  to  the  DOD  mass  memory 
continuously  when  not  using  it.  If  any  other  computer  managed  to 
start  the  mass  memory,  there  would  be  two  sources  of  signal  on  the 
bus,  i.e.,  the  status  check  commands  and  the  mass  memory  data  words. 
This  would  cause  failures  in  bit  count  checks,  parity  checks  and 
sync  bit  checks  at  any  MIA  trying  to  receive  the  data  and  the  data 
would  be  stopped  before  leaving  the  MIA. 

3.3.7  Summary  and  Conclusion  Regarding  Isolation 

In  the  above  text  each  of  the  interfaces  to  equipment  which  can 
store  data  has  been  examined.  For  each  interface,  there  exist  at 
least  three  separate  mechanisms  for  stepping  DOD  information  from 
being  received  and  stored.  It  is  concluded  that  the  system  can 
achieve  isolation.  It  should  also  be  noted,  from  the  start  up 
procedure,  that  only  a very  small  change  is  necessary  in  the  NASA 
primary  system  software  to  get  the  DOD  operation  going.  Only  this 
change  would  have  to  be  verified  with  the  full  rigor  of  flight 
critical  software.  The  DOD  programs,  because  of  the  isolation 
features  cannot  cause  the  primary  system  to  malfunction  and,  thus, 
less  sophisticated  verification  should  be  necessary  with  essen- 
tially no  combined  NASA/DOD  verification  except  for  the  start  up 
feature . 
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3.4 


Effect  of  Synchronization 


The  preceding  section  showed  that  with  the  D00  computer  operating 
in  a non- synchronous  mode,  as  regards  the  primary  system,  a con- 
siderable amount  of  isolation  was  gained.  If  synchronization  was 
retained,  part  of  this  would  be  lost  plus  the  even  more  important 
problem  occurs  in  that  as  part  of  the  synchronized  set  the  DOD 
software  would  have  considerably  more  ability  to  upset  the  opera- 
tion of  the  primary  computer.  This  would  lead  to  requiring  joint 
verification  of  the  programs  operating  together  and  considerably 
more  rigor  in  verification  overall.  These  rather  large  disad- 
vantages would  be  offset  by  the  ability  to  uplink  data  over  the 
existing  hardware  setup  and  to  use  the  Master  Timing  Unit  time 
base  directly.  There  are,  however,  alternate  means  to  receive 
uplink  and  address  the  Master  Timing  Unit. 

3.5  TEMPEST  Considerations 

NASA's  contract  with  Rockwell  International  does  not  acknowledge 
that  the  Orbiter's  computers  will  contain  DOD  classified  data. 

This  stems  from  the  original  negotiations  between  NASA,  Rockwell 
and  DOD  where  the  cost  of  full  TEMPEST  protection  was  deemed  too 
excessive.  The  alternative  to  full  TEMPEST  protection  was  to 
employ  sound  electromagnetic  interference  (EMI)  avoidance  prac- 
tices in  the  design  of  Orbiter  systems  with  special  attention  to 
the  T-Zero  umbilicals,  the  Closed  Circuit  Television  system  and 
the  Payload  Patch  Bulkhead  (located  at  the  aft  station) . DOD 
agreed  to  assume  the  risk  of  further  modifications  if  these  prac- 
tices proved  to  be  inadequate. 

NASA  and  DOD  are  planning  to  perform  TEMPEST  testing  on  the  Orbiter 
currently  at  Palmdale  (Vehicle  099)  sometime  late  in  1981.  These 
tests  will  be  performed  at  the  Orbiter's  external  antennae.  No 
"skin  emanations"  will  be  tested.  If  the  Orbiter  must  be  cleared 
for  classifications  above  SECRET,  skin  emanations  must  be  tested, 
also.  There  are  no  plans  to  perform  testing  between  components 
within  the  vehicle. 

As  soon  as  the  testing  is  completed.  Vehicle  099  will  be  refur- 
bished for  orbital  flight,  regardless  of  the  outcome  of  the  test- 
ing. Vehicles  103  and  104  will  be  modified  as  needed  to  meet 
whatever  TEMPEST  requirements  are  desired.  Vehicles  102  and  099 
will  be  retrofit  with  necessary  modifications  if  it  is  deemed 
necessary  to  have  four  cleared  vehicles. 

3.6  Multi-Experiment  Support 

In  the  isolated  GPC  configuration,  it  is  an  expressed  desire  by  the 
STP  that  experiment  processing  and  data  handling  be  isolated  by 
experiment  within  the  computer.  This,  of  course,  is  a problem 
common  to  all  central  processing  architectures,  GPC  or  not,  and  can 
be  handled  in  a variety  of  ways. 


A particular  feature  of  the  Shuttle  language,  HAI./S,  allows  isola- 
tion by  use  of  the  ACCESS  feature  designed  into  the  language.  This 
feature,  when  applied  to  a HAL/S  program  and  its  attendant  data 
pool,  disallows  any  other  program  from  calling  the  protected  program 
or  accessing  its  data  pool.  (See  Figure  3-2.)  ACCESS-protected  pro- 
grams may,  however,  address  non-protected  programs  and  their  data  as 
shown  by  the  arrow  bridging  the  access  protection  at  the  right  side 
of  the  figure. 

Violations  of  access  rights  are  diagnosed  at  the  time  the  programs 
are  compiled  and  cause  termination  of  the  compilation  if  an  infrac- 
tion occurs.  As  further  protection,  legitimate  compilations  of 
ACCESS-protected  programs  result  in  Program  ACCESS  Files  estab- 
lished for  realtime  control  of  access  rights.  Each  program  is 
given  a Program  Identification  Number  (PIN)  which  is  cross-checked 
in  the  access  files  during  realtime. 

No  software  measures  are  completely  secure.  The  HAL/S  ACCESS  fea- 
ture provides  a measure  of  isolation  which,  under  normal  circum- 
stances, should  provide  the  necessary  data  processing  protection. 
There  are  also  other  techniques  currently  under  investigation  which 
can  increase  multiprocessing  security.  One  of  these  concerns  secure 
operating  systems. 

Several  organizations  are  analyzing  secure  operating  systems  such  as 
the  Strategic  Air  Command  for  use  in  the  Strategic  Air  Command 
Digital  Information  Network  (SACDIN) . Other  methods  of  secure  and 
reliable  software  such  as  modularized  (or  distributive)  systems  with 
rigid  interaction  protocols  are  also  under  investigation. 

3.7  Ground  Systems 

In  addition  to  onboard  support  of  sortie  payloads,  it  may  be 
desireable  to  telemeter  payload-related  data  to  the  ground  for 
analysis.  Under  the  Controlled  Mode  Concept  for  flight  control 
of  DOD  Shuttle  missions  from  NASA/JSC,  payload  telemetered  data 
would  be  throughput,  in  its  original  encrypted  format,  from  the 
Shuttle  to  a remote  Payload  Operations  Control  Center  via  the 
Mission  Control  Center  at  JSC.  This  concept  is  discussed  in  the 
"MCC  STS  and  JSC  POCC  Mature  OPS  Timeframe  Level  A Requirements," 
JSC-12804. 

There  are  other  ground-related  functions  which  must  be  analyzed 
to  ensure  proper  protection  of  DOD  payloads.  Examples  are  the 
use  of  ground  systems  for  preflight  checkout,  premission  and 
real-time  mission  planning,  simulators  and  payload  software 
development.  Assessments  of  these  functions  should  be  made  with 
respect  to  DOD  sortie  missions  before  a commitment  is  made  by 
DOD  for  the  use  of  the  STS  for  sortie  missions. 
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4.0 


Experimental  Data  Processing 


During  a sortie  flight,  the  MASE  will  be  expected  to  support  certain 
realtime  and  quick-look  functions  required  to  operate  experiments 
and  assess  their  performance.  This  section  addresses  the  typical 
requirements  that  could  drive  system  design  and  considers  the  use  of 
in-place  equipment  toward  satisfying  those  needs. 

4 . 1 Approach 

The  problem  divides  basically  into  specification  of  user 
requirements  and  design  of  the  system.  The  approach  »sed  in  this 
report  is  to  first  specify  the  requirements  independent  of  the 
system  design  and  then  to  configure  a system  to  meet  the 
requirements.  In  view  of  the  objective  to  evaluate  system 
capabilities,  specification  of  the  requirements  concentrates  on 
identifying  typical  cases,  rather  than  attempting  to  establish 
strict  groundrules.  The  general  requirement-to-conf iguration 
process  is  illustrated  in  Figure  4-1.  Since  little  information  on 
the  anticipated  sensors  was  available,  a model  of  the  sensor 
characteristics  was  adopted  to  determine  what  possible  data 
manipulations  might  be  applicable  onboard.  An  imager  and  a 
synthetic  aperture  radar  (SAR)  were  adopted  because  their  relatively 
copious  outputs  and  anticipated  processing  workloads  are  expected  to 
drive  the  overall  requirements  and  because  their  processing 
requirements  typify  the  types  of  functions  expected  for  other 
sensors.  The  SAR  outputs  a quasi- image,  which  after  application  of 
a two-dimensional,  digital  integral  transform,  results  in  an  image 
resembling  in  form  the  output  of  an  imager.  It  is  assumed  that  the 
imager  and  SAR  outputs  are  8-bit-values  (i.e.,  measured  to  one  part 
in  2 ) . In  anticipation  of  a wide  spectrum  of  different  image 
sizes,  acquisition  rates  and  data  volumes,  these  characteristics 
were  allowed  to  remain  variable  in  the  sensor  model,  and  the 
requirements  were  established  as  functions  of  them.  This  approach 
was  facilitated  by  considering  the  required  workload  on  a per-image- 
element  or  per-pixel  basis  which  for  many  cases  is  independent  of 
other  data  factors . 

The  functional  requirements  were  established  by  developing  a 
scenario  of  sensor  use.  Based  on  available  information,  it  was 
supposed  that  images  would  be  selected  for  near-realtime  viewing, 
that  is  as  quickly  as  humanly  possible.  The  scenario  identified  the 
six  basic  functions  shown  in  Figure  4-1. 

The  functional  requirements  were  then  transformed  into  system 
requirements,  viz.  processing  loads  and  input/output  (I/O) 
requirements  to  support  performance  of  the  functions  in  a reasonable 
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Figure  4-1  Steps  in  The  Specification  Of  Onboard  User  Requirements 
And  Their  Impacts  On  System  Specification 
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time.  Then,  several  onboard  system  configurations  utilizing  in- 
place  equipment  were  considered,  and  their  capabilities  to  meet  the 
requirements  were  investigated. 

4.2  Data  Processing  Requirements 

Onboard  data  processing  must  support  operation  of  the  sensors  and 
examination  of  their  data  in  near-realtime.  The  duty  cycle  to 
provide  sensor  operation  and  control  is  considered  to  be  low  enough 
that  the  capability  to  support  these  functions  is  not  an  issue. 
Thus,  the  requirements  of  interest  are  limited  to  the  six  functions 
identified  in  Figure  4-1.  These  functions  include  image  inspection 
support  and  SAR  image  production.  They  require  graphics  overlay 
capabilities  for  interactive  display  and  various  computations 
performed  on  the  image  intensity  values.  In  view  of  present 
capabilities  of  the  Multifunction  CRT  Display  System  (MCDS),  the 
graphics  requirements  can  easily  be  met  and  need  not  be  considered 
further . 

The  image  processing  functions  are  presented  in  the  subsections 
below.  Basically,  they  entail  reading  in  the  pixel-by-pixel  array 
of  intensity  values,  performing  certain  computations,  and  reading 
the  resulting  array  of  pixel  values  out  to  a storage  or  display 
unit.  In  determining  workloads  below,  certain  techniques,  such  as 
double  buffering  or  data  blocking,  have  been  assumed  to  allow 
simultaneous  input,  output,  and  processing.  The  functional 
requirements  must  distinguish  between  the  need  for  random  access 
storage  and  satisfaction  with  block-serial  storage.  The  latter  is 
assumed  unless  the  need  for  random  access  is  noted  below. 

4.2.1  Contrast  Enhancement 

The  display  of  a black-and-white  image  is  considered.  The  image  is 
represented  digitally  as  a two-dimensional  array  of  8-bit  words, 
each  representing  the  intensity  of  a small  element  or  pixel  of  the 
image  frame.  The  basic  display  method  consists  of  decoding  each 
pixel  intensity  value  as  a visual  intensity  level  at  the  appropriate 
spot  on  the  screen.  Due  to  limits  in  the  eye's  capability  to 
resolve  intensity  levels,  normally  only  about  8 to  32  levels  are 
displayed.  Contrast  enhancement  entails  a transformation  applied  to 
the  pixel  values  before  display  in  order  to  utilize  the  8,  16,  32, 
etc.,  intensity  levels  for  best  visual  discrimination.  A widely- 
used  method  employs  a linear  transformation  to  place  a desired  range 
of  pixel  intensity  values  in  the  range  of  the  visual  display.  The 
resulting  stretching  of  the  dynamic  range  is  interpreted  visually  as 
a greater  contrast.  A linear  transformation  requires  one  multiply 
and  one  add  per  pixel. 
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Another  common  method  of  contrast  enhancement  effects  a variable 
stretching  of  dynamic  range.  The  dynamic  range  is  stretched  the 
most  at  those  pixel  intensity  levels  represented  by  the  most  pixels. 
This  method  is  used  for  extended  imagery  such  as  of  the  earth's 
surface.  Application  of  histogram  compensation  is  described  in 
Figure  4-2.  Two  data  passes  are  effected.  On  the  initial  histogram 
pass,  the  number  of  pixels  having  intensity  values  at  or  below  a 
given  value  is  determined,  shown  as  an  accumulative  frequency  vs.  8- 
bit  value  in  Figure  4-2.  The  ordinate  of  that  tabular  function  is 
then  rescaled  into  divisions  representing  the  output  display 
intensities,  such  as  from  0 to  15  for  16  levels.  The  second  data 
pass  then  uses  the  table  as  the  transformation  function. 

4.2.2  Demagnification 

In  the  event  that  the  incoming  image  is  larger  than  the  display 
medium,  that  is  the  image  has  more  pixels  than  can  be  displayed  at 
one  time,  either  only  a portion  can  be  viewed  or  the  pixel  density 
must  be  decreased.  This  latter  process  effects  a demagnification, 
as  shown  in  Figure  4-3.  Two  methods  of  reducing  the  pixel  density 
are  in  common  use.  One  method,  called  "decimation"  selects  the 
pixel  in  every  Nth  column  and  Nth  row  for  an  N-fold  demagnification. 
No  computations  beyond  indexing  are  required  for  this  method.  The 
alternate  method  averages  the  N values  from  each  NxN  array  of 
original  pixels  to  produce  the  demagnified  image  pixels.  This 
latter  method  is  preferable  because  all  the  pixel  values  are 
utilized  to  some  extent,  but  this  advantage  is  obtained  at  the  cost 
of  computations:  (N  -1)  adds  and  one  multiply  (by  1/N)  per  output 
sample. 

4.2.3  Magnification 

When  the  size  of  an  image,  in  pixels,  is  smaller  than  that  of  the 
display  medium,  the  image  is  magnified  by  expanding  the  pixel 
density.  Two  alternative  schemes  are  shown  in  Figure  4-4.  The 
simpler  involves  repeating  a pixel  value  N times  in  each  dimension 
for  an  N-fold  magnification.  Thus,  the  display  image  will  consist 
of  blocks  of  NxN  identical  pixel  values,  each  block  representing  a 
magnified  version  of  the  original  pixel.  The  alternate  scheme 
transfers  adjacent  pixels  in  the  unmagnified  image  to  positions 
separated  by  N columns  and  N rows  in  the  new  image.  The  interspaces 
are  filled  in  by  interpolation.  To  preserve  resolution,  cubic 
convolution,  as  presented  in  Reference  4-1,  is  employed  as  follows. 
To  determine  the  pixel  value  in  an  interspace  along  a row,  the  two 
transferred  pixels  (crosshatched  in  Figure  4-4)  on  each  side  are 
used  in  a four-point  weighted  average.  The  weights  are  computed 
from  a third  order  polynomial  function  of  the  relative  distance 
between  each  transferred  pixel  and  the  interspace  position.  Since 


4-4 


there  are  only  (N-l)  interspace  pixels  between  successive 
transferred  pixels,  there  are  only  (N-l)  unique  relative  positions, 
and  a (N-l)x4  matrix  of  weights  can  be  set  up  initially.  After  the 
interspaces  are  filled  along  rows  occupied  by  transferred  pixels, 
the  intermediate  rows  are  filled  by  interpolating  in  the  column 
direction  in  the  same  manner.  This  interpolation  requires  about 
4< 1-1/N)  multiplies  and  3(1-1/N)  adds  per  output  pixel. 

4.2.4  Image  Rotation 

In  special  circumstances,  a rotation  of  the  displayed  image  may  be 
required.  It  is  effected  by  first  computing  the  position  in  the 
unrotated  image  of  each  pixel  in  the  rotated  image.  If  a rotation 
angle  9 is  specified,  the  position,  in  terms  of  the  ith  column,  jth 
row,  in  the  unrotated  image  is  determined  in  terms  of  their 
counterparts  i ' and  j ' in  the  rotated  image  by 

i = Integer  (cos  8 i'  + sin  ft  j'  ) 

j = Integer  (-  sin  ft  i*  + cos  ft  j’). 

where  i,  j,  i',  and  j'  are  indices  with  origin  ( i=j=i ’ =j ' =0)  at  the 
displayed  image  center.  Then,  the  value  of  Pixel  i,j  is  transferred 
to  Pixel  i ’ , j ’ in  the  new  image . Having  chosen  the  integer  values 
in  the  equations  above  effectively  selects  the  "nearest  neighbor" 
pixels,  in  contrast  to  interpolation.  Linear  interpolation  could  be 
utilized  or  the  cubic  convolution  of  the  previous  section  employed, 
but  onboard  quick-look  needs  do  not  seem  to  warrant  that  rigor. 
Because  of  the  non-linear  sequence  of  i and  j resulting  from  a 
linear  sequence  of  i'  and  j'  , random  access  is  required  in 
transferring  pixel  values.  Access  can  be  accommodated  by  first 
loading  the  whole  unrotated  image  into  random  access  memory  or 
loading  workable  segments  of  the  image,  sequenced  to  yield  a 
workable  sequence  of  segments  in  the  rotated  image.  This  latter 
alternative,  though  economical  in  memory  space,  is  less  efficient 
because  overlap  of  the  segments  is  required  to  insure  getting  all 
the  pixel  values. 

4.2.5  Fourier  Transform 

Interest  has  been  expressed  in  being  able  to  generate  a two- 
dimensional  Fourier  transform  of  an  image  onboard.  It  is 
accomplished  by  computing  the  transform  of  each  row  of  pixel  values 
to  generate  intermediate  arrays  of  real  and  imaginary  parts.  The 
transform  of  each  column  of  the  paired  real  and  imaginary  arrays  is 
then  computed  to  obtain  two  transformed  images  corresponding  to  the 
real  and  imaginary  parts,  respectively,  or  the  amplitude  and  phase, 
respectively.  If  the  fast  Fourier  transform  algorithm  is  used,  an 
n-point  transform  requires  2n  log2n  real  multiplies  and  adds.  When 


the  n rows  of  transforms  and  their  repeats  along  the  n columns  are 
considered,  it  is  apparent  that  4 log.n  multiplies  and  adds  per 
sample  are  required.  Random  access  of  storage  is  required,  but  the 
transform  can  be  accomplished  in  blocks  to  reduce  random  access 
storage  at  the  expense  of  increasing  somewhat  the  operations 
required. 


4.2.6  Synthetic  Aperture  Radar  Image-Forming 

The  raw  SAR  image  requires  a two-dimensional  deconvolution  to  obtain 
the  image.  Either  a straightforward  digital  filter  process  can  be 
utilized,  or  the  raw  image  can  first  be  Fourier  transformed,  each 
element  of  the  resulting  "image"  multiplied  by  a stored  function, 
and  the  result  inverse- transformed.  The  latter  method  is  described, 
along  with  the  application  of  certain  corrections,  in  Reference  4-2. 
The  computation  workload  estimated  in  Reference  4-2  for  the  SEASAT-A 
SAR  can  be  applied  to  images  of  other  sizes  by  noting  that  the 
preponderant  computations  are  Fourier  transformation  and  that 
roughly  a 60%  margin  in  the  raw  image  in  excess  of  the  dimensions  of 
the  processed  image  is  required.  The  result  is  that  about  49  log_n 
multiplies  and  adds  per  output  pixel  are  required  to  obtain  an  n-row 
by  n-column  image. 

After  a SAR  image  is  formed,  it  is  subjected  to  the  same  functions 
as  any  other  imagery. 

4.2.7  Requirements  Summary 

The  operations  workloads  required  to  implement  each  function  were 
given  in  the  previous  sections.  They  may  be  expressed  in  terms  of 
General  Purpose  Computer  (GPC)  utilization  by  estimating  the  time 
required  to  execute  the  operations.  The  GPC  code  was  constructed  to 
unpack  8-bit  pixel  values  from  16-bit  half-words,  effect  a linear 
transformation,  and  repack  for  output,  and  the  time  to  execute  the 
resulting  code  was  determined.  For  other  functions,  this  time 
estimate  was  augmented  by  the  appropriate  number  of  add  and  multiply 
intervals.  The  resulting  processing  times  and  the  operations 
workloads  are  presented  in  Table  4-1.  The  omission  of  a workload 
figure  denotes  the  fact  that  the  process  does  not  require  any  excess 
time  when  combined  with  other  processes.  For  example,  decimation 
will  probably  always  be  combined  with  contrast  enhancement. 
Whenever  the  computations  proceed  faster  than  the  input  or  output 
rate,  the  GPC  is  I/O  bound,  and  that  fact  is  noted  by  the 
appropriate  limiter  (input  or  output)  in  Table  4-1.  Input-bound 
processes  are  so  limited  because  there  are  fewer  output  pixels,  and 
the  converse  is  true  for  output-bound  processes . Histogram 
compensation  is  bound  by  two  I/O's  because  two  passes,  each 
requiring  an  input,  are  effected.  The  other  processing  rates  are 
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Table  4-1  Requirements  Impacts  On  Processing 
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expressed  in  terms  of  I/O  rate  for  clarity.  The  processing  for 
convolution  interpolation  requires  2S  times  as  much  time  as  input  of 
the  data.  Fourier  transformation  and  SAR  image- forming  require 
considerably  longer.  To  reconsider  these  processes  in  units  of 
time,  note  that  the  GPC  I/O  time  is  16  microsecond  per  pixel  on  the 
average . 

4.3  Processing  Systems  Configurations 

To  meet  the  requirements  imposed  in  the  previous  section,  several 
onboard  data  system  configurations  are  considered,  representing  a 
system  adhering  to  in-place  equipment  and  augmentations  by 
additional  equipment. 

4.3.1  The  Baseline  System 

The  system  employing  in-place  equipment  alone  is  presented  in  Figure 
4-5.  The  experiment  transmits  selected  data  directly  to  the  GPC 
while  recording  all  data  on  its  own  medium.  Imagery  is  displayed  by 
the  MCDS  by  driving  the  CRT  with  the  Display  Electronics  Unit  (DEU) 
alone.  Although  the  DEU  generates  displays  in  a graphics  mode  only, 
intensity  levels  can  be  displayed  by  a judicious  choice  of  symbols 
coded  in  the  graphics  generation  software. 

The  DEU  display  is  driven  from  a refresh  buffer  of  about  1,500 
words.  When  characters  are  to  be  displayed  at  random  positions, 
three  words  are  required  per  character;  therefore,  about  500 
characters  can  be  displayed.  When  characters  are  uniformly  arranged 
only  one-half  word  each  is  required  for  most  of  them,  and 
considerably  more  than  500  can  be  displayed.  However,  the  time 
required  to  stroke  characters  on  the  screen,  together  with  the 
requirement  to  repeat  the  display  55  times  a second,  restricts  the 
number  of  characters  to  about  1,300,  which  can  accommodate  a small 
image  of  about  36x36  pixels.  These  capabilities  are  illustrated  in 
Figure  4-6.  Apparently,  the  baseline  system  is  limited  to  either 
small  images  of  extended  objects,  as  might  be  generated  by  a high 
energy  detector  or  low  resolution  imager,  or  to  celestial  images 
limited  to  about  500  celestial  point  objects  (stars,  satellites, 
etc.).  In  view  of  the  angular  density  of  stars  as  a function  of 
their  magnitudes  (Reference  4-3) , the  500-star  limitation 
corresponds,  for  example,  to  a field  limited  to  about  4 degrees 
square  when  imaging  stars  down  to  12th  magnitude,  and  to  a field  of 
about  1 arc  min.  square  when  imaging  to  24th  magnitude. 

4.3.2  Video-Augmented  System 

The  bottleneck  in  the  baseline  system  is  caused  by  the  DEU,  and  the 
first  logical  augmentation  is  to  provide  another  video  generation 
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system,  as  shown  in  Figure  4-7.  An  additional  memory  device  is 
inserted  with  a readout  rate  high  enough  to  drive  the  CRT.  A 
candidate  design  employing  disk  storage  is  discussed  in  Section  5. 
The  video  generator  effects  a digital- to-analog  (D/A)  conversion  to 
produce  a signal  resembling  the  video  available  from  the  onboard 
Closed-Circuit  Television  (CCTV)  network.  To  supply  a raster  of 
about  500  lines  with  a bandwidth  equivalent  to  about  500  samples  per 
line,  the  refresh  buffer  must  accommodate  about  250,000  words  or 
about  2 megabits. 

In  this  system,  the  GPC  generates  the  display  image,  and  it  becomes 
the  bottleneck. 

4.3.3  Buffer- Augmented  System 

Even  for  simple  image  manipulations,  the  GPC  limits  the  capability 
in  the  previous  system  by  its  own  Image  storing  capacity  and  by 
being  able  to  input  only  about  5x10  bps  from  an  experiment.  Then, 
the  experiment's  output  rate  would  need  to  be  limited  to  that  value. 
This  limitation  is  lifted  by  inserting  a buffer  between  the 
experiment  and  GPC,  as  shown  in  Figure  4-8.  Selected  images  are 
written  to  the  buffer  at  the  experiment's  output  rate,  possibly  as 
high  as  100  M bps,  and  they  are  read  into  the  GPCs  at  its  rate  of  S M 
bps.  The  buffer's  transfer  rate  must  accommodate  high  experiment 
rates,  and  again  a parallel  arrangement  of  the  disk  units  described 
in  Section  5 can  be  used. 

In  this  configuration,  the  GPC  processing  and  I/O  rates  still  limit 
the  system's  capability  in  terms  of  the  time  required  for  handling 
the  images,  but  data  incompatibilities  with  the  experiment  and 
display  limitations  have  been  removed. 

4.4  GPC-Oriented  System  Response 

By  responding  to  image-handling  limitations  with  the  introduction  of 
the  configurations  of  the  previous  section,  the  overall  system 
limitation  has  been  consolidated  in  the  response  capability.  If  it 
is  assumed  that  buffers  are  added  as  needed  for  the  GPC-CRT  and  GPC- 
experiment  interfaces,  the  system  response  for  different  experiment 
output  rates  and  different  processes  is  shown  in  Figure  4-9. 
Response  functions  are  plotted  for  images  of  512x512  and  1024x1024 
pixels.  For  low  data  rates  the  response  is  limited  by  the  time 
taken  to  transfer  an  image  through  the  system.  As  the  data  rate 
increases,  the  response  time  decreases  until  a horizontal  boundary, 
established  by  the  GPC  processing  or  I/O  rate,  is  reached.  For 
example,  Fourier  transforming  a 1024xl024-pixel  image  requires 
about  4 minutes  in  the  GPC,  regardless  how  fast  the  experiment  can 
output  the  data.  The  lowest  boundaries  are  reached  when  the  GPC's 
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Figure  4-9  GPC  Response  As  A Function  Of  Experiment  Data  Rate 


I/O  restricts  the  flow  of  data  through  the  system.  This  limit  is 
reached  at  about  H N bps. 

Figure  4-10  presents  the  response  in  terms  of  image  size.  Two  data 
rates  are  shown,  corresponding  to  1 K bps  and  the  GPC  I/O-bound  rate 
of  *»  n bps.  Process-limited  responses  are  shown  for  Fourier 
transformation,  SAR  image- forming,  and  convolution  interpolation 
used  for  image  magnification.  In  the  latter  case,  the  image  size 
applies  to  the  output  image.  The  SAR  processing  and  Fourier 
transform  functions  slope  differently  from  the  others  because  of 
their  dependence  on  log.n  for  an  nxn  image.  Figure  4-10  indicates 
that  a 1024x1 024-pixel  TLmage  requires  about  16  seconds  minimum  to 
pass  through  the  system,  about  40  seconds  for  convolution 
interpolation,  about  7 minutes  for  Fourier  transformation,  and  about 
1 hour  for  SAR  image- forming. 

The  overall  capability  of  the  GPC-oriented  system  is  summarized  in 
terms  of  experiment  data  rate  and  image  size  in  Figure  4-11.  For  a 
given  tolerated  response  time,  the  experiment's  data  rate  and  image 
size  must  lie  on  or  below  the  lines  corresponding  to  the  response 
tolerance.  For  example,  if  a 10-minute  wait  time  is  acceptable,  a 
1024xl024-pixel  image  can  be  accommodated  for  any  rate  above  about 
15  K bps.  If  SAR  processing  is  to  be  done  in  10  minutes,  the  image 
cannot  exceed  about  500x500  pixels;  whereas,  Fourier  transformation 
can  accommodate  an  image  a little  larger  than  1024x1024  pixels  in  10 
minutes.  The  I/O-bound  limits  put  absolute  ceilings  on  the  image 
sizes. 
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Figure  4-11  Image  Size  - Data  Rate  Tradeoff 
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HIGH  RESPONSE  SYSTEM 


The  systems  discussed  in  Section  4 utilized  the  Orbiter's  GPC  as 
the  central  processing  unit.  In  those  cases  that  probably  repre- 
sent typical  DOD  experiment  data  processing  requirements  (e.g. 
digital  imagery) , the  GPC  was  the  pacing  unit  in  terms  of  system 
response  time.  In  this  section,  we  will  investigate  a system 
augmented  by  advanced  technology  processors  in  lieu  of  the  GPC 
in  an  attempt  to  improve  the  response  time  of  the  system. 

A survey  of  the  space  processor  technology  which  is  anticipated 
in  the  STP  sortie  timeframe  will  be  given  in  general  terms  and 
a candidate  system  constructed.  This  system  is  not  intended  to 
be  a recommendation,  but  merely  an  example  of  a reasonable-cost, 
reliable  system  which  may  be  available  in  the  1980's. 

5.1  Microprocessor-Augmented  System 

Figure  5-1  illustrates  a typical  system  where  the  GPC  has  been 
replaced  by  a space  microprocessor.  The  GPC  does,  however, 
retain  the  role  of  a central  executive  processor  which  controls 
the  interaction  of  the  other  units  in  the  system.  It  has  been 
determined,  incidently,  that  such  a configuration  - dedicated 
microprocessors  with  a central  controller  - is  the  most  probable 
system  of  the  future. 

In  this  system,  the  experiment  feeds  the  desired  images  to  the 
Selected -Image  Buffer  at  the  experiment  rate.  A microprocessor 
will  extract  data  from  the  buffer  at  a rate  such  that  the  data 
processing  can  be  performed  and  the  processed  data  placed  in 
the  video  refresh  buffer  without  causing  input  data  "pile-up" 
in  the  processor.  It  will,  therefore,  be  an  objective  of  this 
process  to  choose  technologies  which  provide  the  best  system 
matching  rather  than  individually  selecting  the  components  with 
the  most  impressive  performance. 

It  is  also  noteworthy  that  the  microprocessor-augmented  system 
with  the  GPC  as  the  master  controller  retains  the  flexibility 
of  the  GPC's  interactive  features  while  removing  the  security 
concerns  present  when  the  GPC  directly  handles  experiment  data. 

5.2  Technology  Overview 

Two  types  of  systems  were  considered  in  this  brief  technology 
projection  - memories  (for  the  Selected-Image  Buffer  and  the 
video  refresh  buffer)  and  microprocessors. 

Figure  5-2  illustrates  a tree  of  memory  technologies  encompassing 
moving  surface  memory  devices  and  entirely-electronic  memory 
devices.  The  former  includes  tape  disk, and  drum  while  the  latter 
is  made  up  of  random  access  memories  (RAM) , read  only  memories 
(ROM) , serial  access  devices  (which  emulate  moving  surface  mem- 
ories, but  have  no  moving  parts)  and  tunnel  technology.  This 
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Figure  5-1  Microprocessor-Augmented  System 


MEMORIES 


-2  Memory  Technologies 


list  is  by  no  means  exhaustive,  nor  will  a treatise  of  the  various 
technologies  be  given;  but  relevant  factors  such  as  cost,  speed, 
volatility  and  capacity  were  considered  in  designing  a representa- 
tive system. 

Two  terms  must  be  defined  before  analyzing  memories.  They  are: 

Access  Time  - the  average  time  required  to  access  any 
element  of  the  memory 

Cycle  Time  - the  rate  at  which  data  may  be  entered  into 
or  removed  from  memory. 

5.2.1  Memories 

For  random  access  memories,  access  time  and  cycle  time  are  the 
same.  That  is,  each  datum  must  be  sought  out  (since  the  data 
are  stored  randomly)  and  removed  for  output.  Although  this  may 
seem  inefficient,  RAMs  are  the  fastest  memories  currently  avail- 
able. 

Serial  access  devices,  both  moving-surface  and  entirely-electronic, 
may  require  longer  access  times  (the  time  required  to  position  the 
device  to  the  beginning  of  a string  of  data)  than  RAMs,  but  the 
cycle  rate  (input/output  data  transfer  rate)  is  generally  much 
quicker.  Tape  recorders,  for  example,  may  have  average  access 
times  on  the  order  of  seconds  and  cycle  rates  of  10 7 bits  per 
second.  Cycle  time,  therefore,  seems  to  be  the  more  meaningful 
parameter  and  will  be  used  in  the  analysis  of  storage  devices. 

Other  factors  which  should  be  considered  in  the  choice  of  memories 
are  cost,  volatility,  power  and  radiation  resistance.  These 
will  be  mentioned  in  the  analyses. 

Figure  5-3  presents  the  current  access  time  averages  for  various 
memory  technologies.  As  described  earlier,  the  more  exotic 
devices,  RAMs,  require  much  less  time  to  access  a random  element 
in  memory  than  the  slower  (but  less  expensive)  serial  access 
devices.  The  dashed  ellipses  represent  1985  projections  for 
bubble  memories.  The  upper  ellipse  demonstrates  expected  per- 
formance and  cost  for  bubbles  which  are  intended  to  replace 
RAMs.  The  lower  is  bubble  technology  designed  to  replace  disk 
and  drum  devices.  It  should  be  noted  that  these  cost  compari- 
sons hold  for  bubble  memories  storing  up  to  10  million  bits. 
Moving-surface  devices  become  more  cost  advantageous  at  higher 
storage  capacities. 

A more  meaningful  measure  of  capability  for  the  storage  of  serial 
data  is  cycle  (or  data  transfer)  time.  Figure  5-4  presents  this 
parameter  against  cost  and  the  cost  advantage  is  demonstrated 
even  more  dramatically  with  disk,  tape  and  bubble  memories  com- 
paring favorably  with  RAMs.  Another  factor  is  shown  in  this 
figure,  also.  RAM  technology  is  usually  volatile.  That  is,  if 


Figure  5-3  Access/Cost  Comparisons 


Figure  5-4  Cycle  Time/Cost  Comparisons 


if  power  is  lost  to  the  memory,  then  the  device  does  not  retain 
its  contents.  The  serial  access  devices  are  nonvolatile, 
retaining  their  memory  contents  during  power  loss.  One  other 
factor  (not  shown)  is  that  the  fastest  RAMs  are  usually  silicon 
technologies.  Silicon  is  very  susceptible  to  incident  radiation, 
making  its  use  in  space  somewhat  risky  unless  due  hardening  is 
built  in.  Gallium  arsenide  is  a suitable  replacement  for  silicon 
but  results  in  devices  not  as  fast  as  silicon  RAMs.  As  might  be 
expected,  the  volatility  of  the  RAMs  requires  constant  refresh- 
ment of  the  memory  and  drives  the  power  consumption  proportion- 
ately higher. 

5.2.2  Microprocessors 

Microprocessor  technology  for  airborne  and  spaceborne  applica- 
tions is  expected  to  spawn  some  very  capable  devices  in  the  1980s. 
As  Figure  5-5  illustrates,  increases  in  speed  (measured  in 
millions  of  instructions  per  second)  of  an  order  of  magnitude 
will  emerge.  Centralized  processors  (uniprocessors)  will  be  im- 
proved upon  by  4-unit  multiprocessors  (quad  technology)  and 
associative  array  processors.  The  spread  of  the  curves  repre- 
senting a particular  technology  demonstrates  the  different 
speeds  at  which  a microprocessor  can  perform  its  various  func- 
tions (add,  retrieve,  multiply,  etc.).  This  is  clearly  demon- 
strated in  the  associative  array  processor  where  search  (or 
retrieve)  is  about  an  order  of  magnitude  faster  than  a typical 
mix  of  arithmetic  operations. 

Military  and  space  constraints  in  hardening,  reliability  and 
power  have  caused  actual  capabilities  to  lag  somewhat  behind 
previous  predictions.  It  should  also  be  noted  that  airborne 
processors  will  tend  to  be  faster  than  spaceborne  processors 
using  the  same  technologies  due  to  similar  reasons.  The  stringent 
power  requirements  probably  dictate  the  use  of  low-speed/power 
technology  such  as  complementary  metal-oxide  semiconductors. 

Currently,  four  government  agencies  are  supporting  advanced 
signal  processor  development:  1)  DARPA  and  SAMSO  are  jointly 
sponsoring  advance  study  work;  2)  Langley  Research  Center  is 
analyzing  charged-couple  device  (CCD)  analog  signal  processors; 

3)  Goddard  is  planning  to  develop  a Massive  Parallel  Processor 
for  LANDSAT;  and  4)  JPL  is  doing  likewise  for  SEASAT  Progress 
in  these  fields  may  eventually  eliminate  the  disparity  of 
airborne  and  spaceborne  computer  speeds  causing  the  curves  on 
Figure  5-5  to  converge  more  rapidly. 

5.3  Microprocessor-Augmented  System 

Using  the  above  projected  technology  overview,  we  can  now  func- 
tionally design  a system  which  would  be  responsive  to  the  nature 
of  experiments  assumed  in  this  report. 

Beginning  with  the  Selected -Image  Buffer,  Figure  5-6  presents  a 
disk  storage  system  which  can  respond  to  the  100  MBPS  input  rate 


Figure  5-5  Air/Space  Computer  Projections 
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assumed  for  imaging  experiments  and  can  output  at  any  rate  up  to 
the  input  rate.  Disk  technology  was  chosen  for  its  relative 
speed  with  respect  to  tape  and  its  low  cost  as  evidenced  by 
Figure  5-4.  Bubble  technology  was  not  considered  as  a viable 
candidate  now  as  too  little  is  known  to  produce  the  same  level 
of  detail  as  for  disk.  Secondly,  an  earlier  discussion  revealed 
that  bubble  memory  cost  increases  dramatically  if  the  total  stor- 
age exceeds  10  million  bits.  Our  particular  scenario  requires  5 
frames  of  1024  x 1024  pixels  of  8 bits  each  or  about  40  million 
bits.  Typical  specifications  of  this  system  are: 


Storage 
Input  Rate 
Weight 
Volume 
Power 

Availability 


- 10*  bits 

- 100  MBPS 

- 20  lbs. 

- 0.7  cu . ft. 

- 75  watts 

- early  80s 


This,  of  course,  is  a multiple  disk , multiple  read  head  configura- 
tion which  brings  the  data  transfer  rate  up  to  the  desired  10* 

BPS  as  opposed  to  the  projected  0.5-1  x 10 7 BPS  rate  on  Figure 
5-4.  Multiple  bubble  memories  could  be  paralleled  as  well  to 
produce  fast  I/O  rates. 


With  this  in  mind,  it  would  seen  that  the  I/O  rate  could  be  in- 
creased without  bound  then  the  pacing  element  would  be  the  speed 
with  which  the  processor  could  handle  the  data.  If  we  conserva- 
tively chose  the  4-unit  multiprocessor  curve  on  Figure  5-5,  we 
find  that  1985  technology  for  spaceborne  processors  would  yield 
a 20  MOPS  device.  Similar  calculations  can  be  performed  for 
other  years. 


On  the  other  hand,  we  might  assume  the  use  of  a single  unit 
storage  device  for  less  stringent  problems  with  a microprocessor 
which  is  matched  in  speed  to  the  storaqe  device.  If  we  assume 
this  single  storage  device  to  be  a bubble  memory  of  average 
predicted  speed,  we  are  bound  by  the  data  transfer  rate  as  be- 
fore (with  the  GPC)  and  can  also  be  bound  by  the  computational 
speed  in  the  case  that  a speed-matched  microprocessor  is  used. 

Figure  5-7  illustrates  the  system  response  time  for  a micro- 
processor-augmented system.  The  solid  lines  represent  a single 
bubble  memory  device  for  the  Selected-Image  Buffer  with  a speed- 
matched  microprocessor.  The  dashed  line  represents  a system 
where  parallel  systems  are  utilized  for  the  Selected-Image  Buffer 
such  that  the  microprocessor  becomes  the  pacing  element.  The 
microprocessor  speed  is  then  extracted  from  Figure  5-5,  4-Unit 
Multiprocessor  (Space) . It  is  clear  in  comparison  with  Figure 
4-9  that  substantial  savings  can  be  produced  usinq  predicted 
space  systems  technology. 
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CONCLUSIONS  & RECOMMENDATIONS 


The  use  of  the  Orbiter's  General  Purpose  Computers  as  an  element 
in  a Manned  Aerospace  Support  Equipment  system  has  been  analyzed 
from  two  aspects.  The  first  scrutinized  the  security  risk  in 
isolating  one  of  the  computers  from  the  other  four.  The  second 
investigated  the  response  of  a GPC-oriented  system  to  several 
typical  experiment  processing  requirements.  Augmentation  of  the 
GPC-originated  system  was  discussed  to  render  it  applicable  to  the 
various  experiments . 

6.1  Security 

On  the  security  issue,  it  was  concluded  that  measures  which  are 
already  built  into  the  NASA  system  could  be  taken  to  isolate  a 
single  computer  from  the  others  with  at  least  three  levels  of 
testing  (error  checking)  insulation  in  all  areas.  By  simply 
causing  the  computer  to  be  "out  of  sync"  with  the  others  (a  con- 
dition which  would  occur  in  the  NASA  system  if  one  computer 
failed) , precautions  are  taken  by  both  the  isolated  computer  and 
the  remaining  set  to  insulate  one  from  the  other.  Various  minor 
precautions  (e.g.,  a unique,  hand-entered  identification  number 
for  the  DOD  Mass  Memory)  can  be  taken  to  further  secure  the 
system. 

It  was  further  concluded  that,  although  TEMPEST  testing  was  not 
to  be  conducted  internal  to  the  Orbiter,  the  Orbiter's  Data  Pro- 
cessing System  should  easily  conform  to  all  emanations  testing. 

Likewise,  the  handling  of  data  and  processing  software  from 
several  experiments  simultaneously  is  provided  for  in  the  current 
Shuttle  language  (HAL/S) . 

It  was  also  noted  that  the  use  of  a double  encryption  baseline, 
where  encrypted  payload  data  is  interleaved  with  Orbiter  telemetry 
data  and  encrypted  again  by  the  Orbiter  before  being  telemetered 
to  JSC,  may  relieve  any  ground  systems  concerns.  Under  this 
system,  NASA/JSC  would  decrypt  the  telemetry  stream  (leaving  the 
payload  data  encrypted)  and  route  the  payload  data  to  a remote 
Payload  Operations  Control  Center  causing  payload  operations  to 
be  functionally  independent  of  the  "Controlled  Mode"  concept. 

Some  areas  for  further  analysis  include  the  ramifications  of  pre- 
flight checkout  on  security  (a  problem  common  to  both  the  isolat- 
ed GPC  concept  and  a dedicated  MASE  system  concept),  the  use  of 
a sixth  GPC  at  the  aft  station  in  lieu  of  isolating  one  of  the 
standard  five  and  the  use  of  specialized  equipment  under  GPC 
control.  Software  security  measures  may  also  be  investigated, 
such  as  secure  (multi-level)  operating  systems,  modular  soft- 
ware systems  with  rigid  protocol,  fault-tolerant  systems  and 
improved,  reliable  languages. 
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6.2  System  Response 

After  having  generated  data  processing  requirements  for  typical 
experiments  in  which,  it  is  assumed,  the  STP  would  be  interested, 
the  response  of  a GPC-centered  computer  system  (necessarily  aug- 
mented by  other  components)  was  analyzed.  A particular  experi- 
ment - the  storing  of  high-speed  digital  imagery  data  on  an  inter 
mediate  buffer  and  the  subsequent  display  of  this  1024  x 1024 
8-bit  pixel  image  in  a 512*  format  - could  be  supported  in  about 
16  seconds.  The  same  experiment  which  further  required  a Fast 
Fourier  Transform  to  be  performed  on  the  data  could  be  processed 
in  approximately  one  minute.  These  times  seem  reasonable  for 
the  purpose,  but  may  be  substantially  improved  by  replacing  the 
GPC  as  the  data  processing  element  with  specialized  micro- 
processors (as  predicted  to  the  1985  timeframe) . Times  for  the 
1024*  to  512*  demagnification  and  the  5122  Fast  Fourier  Transform 
could  be  reduced  to  0.1  seconds  and  1 second,  respectively,  if 
technology  predictions  are  accurate. 

There  are,  of  course,  several  tradeoffs  that  should  be  conducted 
before  a faster,  more  exotic  system  is  recommended.  On  the  one 
hand  is  the  speed  of  response  offered  from  systems  anticipated 
for  space  technology,  while  on  the  other  is  the  reliability, 
relatively  low  cost  and  guaranteed  Shuttle  program  support 
offered  with  use  of  the  Orbiter's  Data  Processing  System.  Cost, 
power,  logistics,  software  development  and  testing,  simulators 
and  other  factors  must  be  considered. 

IBM  is  not  recommending  any  one  method.  This  decision  can  only 
be  made  when  definitive  data  processing  requirements  are  de- 
lineated and  the  impact  of  satisfying  those  requirements  eval- 
uated. It  is  recommended  that  the  proper  action  be  taken  to  per- 
form these  evaluations  as  the  cost  of  necessary  changes  to  the 
NASA  system  (provided  any  are  required)  may  mount  with  time. 
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ABBREVIATIONS  AND  ACRONYMS 


BCE 

BPS 

CCD 

CCTV 

CPU 

CRT 

cu.  ft. 

D/A 

deg. 

DEU 

DK 

DOD 

EMI 

exper. 

PC 

FOV 

G 

GPC 

hr. 

IBM 

I/O 

IOP 

IPL 

IUA 

JPL 

JSC 

K 


Bus  Control  Element 
Bits  Per  Second 
Charge-Coupled  Devices 
Closed  Circuit  Television 
Central  Processing  Unit 
Cathode  Ray  Tube 
cubic  feet 
Digital  to  Analog 
degrees 

Display  Flectronics  Unit 

Display/Keyboard 

Department  of  Defense 

Electromagnetic  Interference 

experiment 

Flight  Control 

Field  of  View 

Giga  (10*) 

General  Purpose  Computer 
hours 

International  Business  Machines  Corporation 

Input/Output 

Input/Output  Processor 

Initial  Program  Load 

Interface  Unit  Address 

Jet  Propulsion  Laboratories 

Johnson  Space  Center 

Kilo  (10*) 


KBPS 

LANDSAT 

lbs. 

LDB 

M 

mag. 

MASE 

MBPS 

MCDS 

MDM 

MIA 

min. 

MMU 

MOPS 

NASA 

NRZ 

PCI 

PCO 

proc. 

RAM 

ROM 

SAR 

SEASAT 

sec. 

STP 

STR 

Xform 


Kilobits  per  Second 
Land  Satellite 
pounds 

Launch  Data  Bus 

Mega  ( 10  6 ) 

magnetic,  magnitude 

Manned  Aerospace  Support  Equipment 

Megabits  per  Second 

Multifunctional  CRT  Display  Station 

Multiplexer/Demultiplexer 

MDM  Interface  Adapter 

minutes 

Mass  Memory  Unit 
Megaoperations  per  Second 

National  Aeronautics  and  Space  Administration 

Non-Return-to-Zero 

Program  Controlled  Input 

Program  Controlled  Output 

Processing 

Random  Access  Memory 

Read  Only  Memory 

Synthetic  Aperture  Radar 

Sea  Satellite 

seconds 

Space  Test  Programs 
Standard  Test  Rack 
Transform 
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